Overcoming Team Dysfunctions: Merging Scrum and Kanban catalyzed cultural transformation and significant delivery speed improvements.
Overview
A mature but misaligned development team supporting a ten-year-old product faced persistent delivery issues, process confusion, and morale challenges. The team was left disoriented after an extremely lengthy and exhaustive platform migration, working in fragmented Sprints, juggling multiple Backlogs, and accumulating incomplete work. Despite declaring the use of Scrum, actual practices significantly lacked coherence and flow.
With support from Professional Scrum Trainer Alex Hardt, Daniel Mark led the charge to reshape the team’s approach. Within nine months, they improved their time-to-market by 1.200% — moving from one release every three sprints to delivering three releases per sprint. The shift was not just procedural; it catalyzed cultural and behavioral change across the team.
Challenges
The dysfunctions were layered:
- No accountability or buy-in for the framework’s roles, events, and artifacts.
- A mechanical Scrum practice that lacked purpose, energy, and teamwork.
- Missing sense of quality reflected in a non-existent Definition of “Done”.
- Prolonged misalignment and friction have created a siloed environment.
- A climate of blame persisted between development and business.
- Chronic overcommitment in Sprint Planning led to missed goals.
- An abundance of “orphaned” work items—started but never completed.
- Low trust with stakeholders.
- Total absence of metrics.
The result was poor predictability, slow, error-prone releases, and a demoralized, burned-out team unable to deliver value confidently.
Initiating Change
After attending Scrum.org's Professional Scrum with Kanban (PSK) beta class, Alex returned energized to share his learning. Daniel, who had been searching for a practical path forward, allowed Alex to translate the class insights into a real-world evolution.
Rather than launching a sweeping transformation, Alex followed Kanban’s principle: “Start with what you do know.” He focused on visualizing work, introducing Flow Metrics, and iteratively making incremental, measurable improvements.
The catalyst was data, specifically, Flow Metrics. More importantly, it initiated meaningful change by revealing the behavior behind the numbers and consequently improving them.
Solution
1. Defining Flow and Creating Focus
The team started by mapping their workflow. They agreed on when work was considered started and finished, and they started to take a deeper look at the Work Item Age.
That’s when the “Orphans” became visible—items they’d started but never finished. One by one, they addressed them:
- Archived what was obsolete.
- Sliced large items into shippable parts.
- Limited WIP and focused on completing rather than starting.
This alone made a visible impact. They were reducing flow debt for the first time, rather than accumulating it.
The team began limiting their Work Item Progress (WiP) by actively managing Work Item Age and consequently finished more items than started new ones. More and more Work in Progress Limits were honored. Over time, the system became healthy, and the flow debt significantly reduced.
The work piled up, primarily in the Integration column, was another source of flow debt, leading to a long Cycle Time and low Release Frequency. Focusing on reducing organizational issues in that column gave a boost both in reducing Cycle Time and improving Release Frequency.
2. Rebuilding Scrum Through a Flow Lens
- Sprint Planning: They replaced gut-feel forecasting with a Monte Carlo “How Many” simulation based on historical Throughput. That grounded their plans in reality, not optimism.
- Daily Scrums: Instead of individual status updates, they walked the board from right to left, looking at what was stuck, aging, or blocking. Developers began to collaborate and prioritize finishing their work as a unit. The event became energizing, not draining.
- Sprint Retrospectives: Flow Metrics transformed them into evidence-based workshops, rather than venting sessions. The Scrum Values became vivid.
3. Refinement Discipline
The team noticed they were over-preparing items. A Monte Carlo “When” simulation showed them that they had ready items for more than five Sprints. The simulation was also helpful in preventing the Product Backlog from being flooded with new items. That way, the team freed up time and refined with more intent, creating a shared understanding of what they want to achieve together. These refinements, in particular, closed the gap in cooperation between business and development.
4. Estimation Evolution
Their estimation also matured. Rather than using Story Points, the team shifted to time-based forecasting: how many weeks would it take to complete the task? With 3-week Sprints, the range was simple: 1, 2, or 3. It wasn’t textbook, but it worked—it shifted focus to flow rather than effort. It also helped during Sprint Planning to forecast the number of items to be pulled into the Sprint Backlog. Additionally, this allowed them to identify which items needed to be started early in the Sprint to be completed before the end of the Sprint.
Results
Within nine months, the impact was undeniable:
- Cycle time shortened dramatically. From an 85% probability of 168 days to 18 days.
- The achievement rate of Sprint Goals increased by 200%.
- The Release Frequency increased by 1.200%.
- Forecast accuracy improved, and overcommitment dropped.
The team didn’t just improve at Scrum and their delivery—they started enjoying the work again.
Conclusion
This transformation made the team’s delivery system reliable. By integrating Kanban into their Scrum implementation, they introduced the structure, transparency, and flow control that had been missing. Work stopped falling through the cracks. Forecasts became evidence-based. Sprint Goals became achievable.
They didn’t change the framework—they changed how they used it. The result was faster releases, fewer blockers, higher trust, and a team that finally had the tools to own and improve its ways of working.
“Over time, the team transformed from a quarreling bunch of individuals into a solution-focused and mutually respectful community. We didn’t just fix delivery—we rediscovered our rhythm, our voice, and our confidence as a team.”
— Daniel Mark
Now that the team can work in small batches and deliver customer value frequently, they can run more experiments and shift their focus toward improving customer outcomes.
If you're navigating dysfunction in a Scrum environment, the advice is simple: don't abandon it—evolve it.